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FOREWORD 


A  Guide  to  Understanding  Object  Reuse  in  Trusted  Systems  provides  a  set  of 
good  practices  related  to  object  reuse.  We  have  written  this  guideline  to  help  the 
vendor  and  evaluator  communities  understand  the  requirements  for  object  reuse  as 
described  in  the  Department  of  Defense  Trusted  Computer  System  Evaluation  Crite¬ 
ria.  In  an  effort  to  provide  guidance,  we  make  recommendations  in  this  technical 
guideline  that  are  not  requirements  in  the  Criteria. 

The  Object  Reuse  Guide  is  the  latest  in  a  series  of  technical  guidelines  published  by 
the  National  Computer  Security  Center.  These  publications  provide  insight  to  the 
Trusted  Computer  System  Evaluation  Criteria  requirements  for  the  computer  security 
vendor  and  technical  evaluator.  The  goal  of  the  Technical  Guideline  Program  is  to 
discuss  each  feature  of  the  Criteria  in  detail  and  to  provide  the  proper  interpretations 
with  specific  guidance. 

The  National  Computer  Security  Center  has  established  an  aggressive  program  to 
study  and  implement  computer  security  technology.  Our  goal  is  to  encourage  the 
widespread  availability  of  trusted  computer  products  for  use  by  any  organization 
desiring  better  protection  of  its  important  data.  One  way  we  do  this  is  by  the  Trusted 
Product  Evaluation  Program.  This  program  focuses  on  the  security  features  of  com¬ 
mercially  produced  and  supported  computer  systems.  We  evaluate  the  protection 
capabilities  against  the  established  criteria  presented  in  the  Trusted  Computer  Sys¬ 
tem  Evaluation  Criteria.  This  program,  and  an  open  and  cooperative  business 
relationship  with  the  computer  and  telecommunications  industries,  will  result  in  the 
fulfillment  of  our  country’s  information  systems  security  requirements.  We  resolve  to 
meet  the  challenge  of  identifying  trusted  computer  products  suitable  for  use  in  pro¬ 
cessing  information  that  requires  protection. 

I  invite  your  suggestions  for  revising  this  technical  guideline.  We  will  review  this  doc¬ 
ument  as  the  need  arises. 


Director 

National  Computer  Security  Center 


July  1992 
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1.0  INTRODUCTION 


1.1  BACKGROUND 

The  principal  goal  of  the  National  Computer  Security  Center  (NCSC)  is  to  en¬ 
courage  the  widespread  availability  of  trusted  computer  systems.  In  support  of  this 
goal  the  NCSC  created  a  metric,  the  DoD  Trusted  Computer  System  Evaluatiorr  Cri¬ 
teria  {TCSEC)  [2],  against  which  computer  systems  could  be  evaluated. 

The  TCSEC  was  originally  published  on  15  August  1983  as  CSC-STD-001-83.  In 
December  1985  the  Department  of  Defense  adopted  it,  with  a  few  changes,  as  a 
Department  of  Defense  Standard,  DoD  5200.28-STD.  DoD  Directive  5200.28,  Secu¬ 
rity  Requirements  for  Automated  Information  Systems  (AISs)  [4],  requires  the  TCSEC 
be  used  throughout  the  Department  of  Defense.  The  TCSEC  is  the  standard  used 
for  evaluating  the  effectiveness  of  security  controls  built  into  DoD  AISs. 

The  TCSEC  is  divided  into  four  divisions:  D,  C,  B,  and  A.  These  divisions  are  or¬ 
dered  in  a  hierarchical  manner,  with  the  highest  division  (A)  being  reserved  for  sys¬ 
tems  providing  the  best  available  level  of  assurance  and  security.  Within  divisions  C 
and  B  are  subdivisions  known  as  classes,  which  are  also  ordered  in  a  hierarchical 
manner  to  represent  different  levels  of  security  in  these  divisions. 

1.2  PURPOSE 

This  document  is  written  to  help  vendors  and  evaluators  understand  the  object 
reuse  requirement.  It  also  provides  guidance  to  vendors  on  how  to  design  and  incor¬ 
porate  effective  object  reuse  mechanisms  into  their  systems.  Some  examples  for 
accomplishing  object  reuse  are  provided  in  this  document,  but  they  are  not  the  only 
way  to  meet  the  requirement.  Nor  are  the  recommendations  supplementary  require¬ 
ments  to  the  TCSEC.  The  only  measure  of  TCSEC  compliance  is  the  TCSEC  itself. 

1.3  SCOPE 

This  guideline  discusses  the  object  reuse  requirement  applicable  to  the  trusted 
computing  bases  (TCBs)  found  in  classes  C2  through  A1.  Although  it  is  directed  to¬ 
ward  object  reuse,  this  guideline  also  addresses  other  TCSEC  requirements  that 
tend  to  strengthen  the  assurance  for  the  correct  performance  of  object  reuse. 
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1.4  CONTROL  OBJECTIVE 

The  general  control  objective  for  object  reuse  is  specified  in  the  TCSEC.  It  was 
originally  obtained  from  DoD  Directive  5200.28  (April  ’78  version)  which  has  now 
been  modified  and  reissued  (March  ’88)  but  still  embodies  the  spirit  of  the  original 
requirement.  It  requires  automated  information  systems  (AISs)  processing  classified 
information  to,  “with  reasonable  dependability,  prevent: 

a.  Deliberate  or  inadvertent  access  to  classified  material  by  unauthorized  per¬ 
sons  .  .  .  .”  [2,  page  59] 

The  word  “unauthorized”  in  the  above  objective  is  deserving  of  further  explana¬ 
tion.  Certainly  one  must  assume  that  strong  Identification  and  Authentication  (I  &  A) 
mechanisms  ensure  that  users  are  authorized  to  be  on  the  system  prior  to  the  need 
for  object  reuse  controls.  However,  the  object  reuse  mechanisms  are  designed  to 
ensure  that  the  authorized  user  of  the  system  does  not  obtain  residual  information 
from  system  resources. 

In  this  guideline,  “classified”  means  any  information  requiring  protection  or  au¬ 
thorization  to  access.  The  disclosure  arising  from  the  absence  of  an  object  reuse 
mechanism  is  considered  inadvertent  (assuming  all  other  TCSEC  requirements  are 
in  place  and  working  properly). 


2 


2.0  OVERVIEW  OF  PRINCIPLES 


Object  reuse  is  defined  by  A  Guide  to  Understanding  Data  Remanence  in  Auto- 
mated  Information  Systems  as: 

“The  reassignment  to  some  subject  of  a  storage  medium  (e.g.,  page  frame, 
disk  sector,  magnetic  tape)  that  contained  one  or  more  objects.  To  be  securely 
reassigned,  no  residual  data  can  be  available  to  the  new  subject  through  stan¬ 
dard  system  mechanisms.”  [1] 

The  object  reuse  requirement  of  the  TCSEC  is  intended  to  assure  that  system 
resources,  in  particular  storage  media,  are  allocated  and  reassigned  among  system 
users  in  a  manner  which  prevents  the  disclosure  of  sensitive  information. 

The  requirement  ultimately  derives  from  observations  made  during  the  early 
penetration  testing  experiences  (circa  1969-1973)  that  systems  typically  did  not 
clear  a  user’s  working  memory  (often  called  “scratch  space”)  when  the  user  com¬ 
pleted  a  session.  Thus,  when  memory  was  reassigned  to  another  user,  the  informa¬ 
tion  placed  in  it  by  the  previous  user  was  now  available  to  the  new  owner  of  the 
scratch  space.  Often,  the  disclosure  was  inadvertent;  the  second  user  had  not  in¬ 
tended  to  obtain  the  information  suddenly  made  available.  However,  it  also  meant 
that  a  malicious  (or  just  curious)  user  could  browse  (or  “scavenge”)  through  the 
system,  obtaining  scratch  space  and  looking  for  items  of  interest  (the  equivalent  of 
rummaging  through  the  trash).  Depending  upon  the  details  of  the  system  architec¬ 
ture  and  operating  system,  a  browser  could  more  or  less  control  whose  work  space 
was  being  accessed.  Although  the  problem  was  first  noted  as  one  involving  primary 
storage  (or  main  memory),  it  clearly  extends  to  secondary  storage  as  well;  remov¬ 
able  media  (such  as  tapes  and  removable  disks)  and  disk  space  must  be  allocated 
such  as  to  prevent  one  user’s  information  from  inadvertently  becoming  available  to 
others  as  system  storage  resources  are  shared  among  system  users. 

In  short,  with  effective  object  reuse  mechanisms  in  place,  a  penetrator  is  pre¬ 
vented  from  obtaining  information  through  browsing  attacks  (e.g.,  logging  onto  the 
system  as  a  user  and  browsing).  Object  reuse  does  not  necessarily  protect  against 
physical  attacks  on  the  storage  medium,  especially  using  sophisticated  equipment 
and  methods  (e.g.,  taking  a  degaussed  disk  pack  and  trying  to  read  residual 


3 


OBJECT  REUSE  GUIDELINE 


information  from  the  platters).  Protection  against  physical  attacks  are  addressed  by 
A  Guide  to  Understanding  Data  Remanence  in  Automated  Information  Systems  [1]. 

2.1  THE  TCSEC  OBJECT  REUSE  REQUIREMENT 

The  object  reuse  requirement  first  appears  at  class  C2  (controlled  access  pro¬ 
tection)  and  remains  unchanged  through  class  A1  (verified  protection).  Although  the 
requirement  remains  unchanged,  the  assurance  of  proper  implementation  increases 
as  the  class  increases. 

The  requirement  is: 

“All  authorizations  to  the  information  contained  within  a  storage  object  shall 
be  revoked  prior  to  initial  assignment,  allocation  or  reallocation  to  a  subject  from 
the  TCB’s  pool  of  unused  storage  objects.  No  information,  including  encrypted 
representations  of  information,  produced  by  a  prior  subject’s  actions  is  to  be 
available  to  any  subject  that  obtains  access  to  an  object  that  has  been  released 
back  to  the  system.  ”  [2,  page  1 5] 

The  term  “storage  object”  is  defined  as: 

“An  object  that  supports  both  read  and  write  accesses.”  [2,  page  116] 

The  intent  of  the  object  reuse  requirement  is  stated  in  the  second  sentence  of 
the  requirement  above  (“No  information  .  .  .  produced  by  a  prior  subject’s  actions  is 
to  be  available  to  any  subject  that  obtains  access  to  an  object  that  has  been  re¬ 
leased  back  to  the  system.”)  Rephrased,  the  purpose  is  to  prevent  a  user  who  is  al¬ 
located  storage  from  accessing  information  put  there  by  a  previous  user  (ignoring, 
for  the  moment,  explicit  sharing).  It  also  has  the  side  effect  of  preventing  a  user 
from  accessing  information  he  puts  into  a  storage  object  which  is  released  to  the 
system  and  then  reallocated  to  him. 

The  requirement  does  not  specify  how  to  perform  object  reuse.  It  allows  the  de¬ 
signer  some  leeway  in  implementation.  An  obvious  approach  is  to  clear  the  storage, 
either  upon  deallocation  or  at  allocation.  Either  method  is  acceptable  in  meeting  the 
requirement,  although  there  are  tradeoffs  to  consider  when  making  this  choice. 
These  issues  are  discussed  later  in  this  guideline.  However,  the  designer  can  use 
an  approach  which,  in  effect,  guarantees  that  the  current  “owner”  of  the  storage  can 
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only  access  what  he  has  written  (e.g.,  preventing  the  reading  beyond  the  end-of-file 
mark  on  a  tape  or  in  a  disk  block).  Thus,  the  wording  of  the  requirement  recognizes 
the  existence  of  different  implementation  strategies  which  accomplish  the  same  end. 

The  first  sentence  of  the  requirement  (“All  authorizations  to  the  information  con¬ 
tained  within  a  storage  object  shall  be  revoked  means  that  once  a  storage  ob¬ 
ject  is  given  to  a  user,  no  subject  can  have  access  to  the  information  which  had 
been  (or  may  still  be)  in  that  object.  “All  authorizations  to  the  information  contained 
within  a  storage  object  shall  be  revoked . . . .”  does  not  equate  to  “no  subject  can 
have  access  to  that  object’s  contents.”  Nor  does  it  equate  to  revoking  the  authoriza¬ 
tion  attributes  (e.g.,  read,  write,  execute  or  append)  assigned  to  information  within  a 
storage  object.  Why?  Because  if  the  vendor  chooses  to  clear  the  storage  object 
“prior  to  initial  assignment,  allocation  or  reallocation,”  he  has  revoked  “all  authoriza¬ 
tions  to  the  information  contained  within  [the]  storage  object.”  The  focus  is  on  the 
information— not  the  storage  object,  not  the  attributes. 

Does  object  reuse  require  the  revocation  of  authorization  attributes  (e.g.,  read, 
write,  execute  or  append)  assigned  to  information  within  a  storage  object  before  it  is 
assigned  or  allocated?  It  depends  upon  the  particular  implementation.  Suppose  a 
system  uses  memory  segments  with  read,  write,  execute,  and  append  attributes  en¬ 
coded  into  descriptors.  If  the  information  in  the  segment  has  been  overwritten,  there 
is  no  need  to  clear  the  descriptor  unless  the  descriptor  is  considered  part  of  the 
storage  object  or  is  itself  a  storage  object  which  is  released  to  the  system.  If  the  de¬ 
scriptor  is  considered  a  storage  object  or  part  of  one,  the  attributes  are  information 
subject  to  the  object  reuse  requirement.  In  both  cases,  the  system  could  overwrite 
the  old  attributes  with  the  new  user’s  attributes.  Or  it  could  remove  all  attributes  at 
deallocation.  Either  way,  clearing  the  attributes  only  assures  that  granting  access  to 
a  pooled  storage  object  (in  this  case,  a  segment)  does  not  implicitly  give  access  to 
any  data  previously  contained  in  the  object.  The  information  within  the  storage  ob¬ 
ject  must  still  be  protected  from  the  new  owner. 

Consider  the  case  when  a  parent  process  initiates  one  or  more  subordinate 
processes,  each  having  access  to  a  file  owned  by  the  parent.  Suppose  the  parent 
process  deletes  the  file,  and  the  file  space  (disk  space,  for  example)  is  returned  to 
the  system’s  resource  pool.  Does  proper  object  reuse  also  require  the  removal  of 
the  subordinate  processes’  access  permissions  to  the  file  space  upon  deallocation? 
No,  the  requirement  allows  the  system  to  leave  the  access  set  to  the  parent  and/or 
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the  offspring  processes,  but  only  to  those  processes.  This  guarantees  that  no  other 
processes  can  access  the  information  in  the  workspace  until  the  proper  procedures 
are  followed.  The  requirement  does  not  say  “revoke  authorizations  at  deallocation  of 
storage  objects”— the  requirement  does  not  care  if  access  is  continued  to  be  al¬ 
lowed  to  the  process  that  caused  the  information  to  appear  in  the  storage  object  be¬ 
fore  the  object  is  reassigned.  In  other  words,  a  subject  could  retain  effective  access 
to  an  object  that  had  been  returned  to  the  “free  pool”  until  that  object  was  reallocat¬ 
ed.  {Note;  We  can  think  of  no  reason  for,  nor  an  actual  implementation  of,  the  above 
approach.  We  mention  it  only  to  make  a  point.) 

Strictly  speaking,  the  TCSEC  object  reuse  requirement  only  applies  to  storage 
objects  accessible  by  untrusted  users  of  an  AIS.  However,  the  system  designer  may 
choose  to  ensure  that  internal  security  relevant  data  structures  are  also  properly 
cleared  when  reusing  the  internal  object.  This  internal  data  structure  clearing  may 
occur  via  explicit  action  of  the  Trusted  Computing  Base  (TCB),  or  it  may  be  implicit 
via  a  complete  overwrite  with  new  TCB  data. 

An  example  which  illustrates  these  issues  is  shown  using  Figure  1 .  In  this  exam¬ 
ple,  a  segmented  memory  system  provides  for  virtual  storage  to  system  users,  us¬ 
ing  a  segment  map  table  (SMT)  to  maintain  segment  control  information.  Control  of 
access  to  the  storage  object  (i.e.,  memory  segment)  is  effected  by  setting  the  ap¬ 
propriate  access  attributes  to  1  (access  permitted)  or  0  (access  not  permitted). 
Thus,  an  SMT  description  pertaining  to  a  segment  allocated  to  subject  S1  for 
read/write  access  would  reflect  an  attribute  coding  of  R  =  1 ,  W  =  1 ,  E  =  0,  and  A  =  0 
(or  1100). 

To  satisfy  the  TCSEC  object  reuse  requirement,  the  TCB  must  perform  several 
different  actions  with  respect  to  the  segment  and  the  SMT.  The  TCB  must  ensure 
that  the  segment  is  accessible  only  through  known,  TCB  controlled,  mechanisms 
such  as  the  SMT.  This  assures  the  invocation  of  the  TCB  whenever  an  access  de¬ 
cision  must  be  made.  The  TCB  must  not  permit  access  (by  a  new  subject)  to  the 
segment  until  the  segment  is  specifically  allocated  to  a  subject.  The  TCB  must  en¬ 
sure  the  segment  is  clear  (i.e.,  contains  no  residual  data)  either  by  explicitly  clearing 
the  segment  at  allocation,  clearing  the  segment  at  deallocation,  or  completely  over¬ 
writing  the  segment  with  new  data  which  the  subject  assigned  the  segment  is  per¬ 
mitted  to  access  in  the  assigned  mode.  The  TCB  must  also  ensure  the  clearing  of 
any  residual  control  information  (i.e.,  internal  TCB  data  structure)  before  reallocating 
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SEGMENT  MAP  TABLE  DESCRIPTION 
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Bit 
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Address 
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B 
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■ 

R  -  Read  Attribute  W-  Write  Attribute 

E  -  Execute  Attribute  A  -  Append  Attribute 

Figure  1 


the  segment  (if  the  control  information  is  contained  within  a  storage  object).  For  ex¬ 
ample,  if  SMTs  are  considered  storage  objects,  the  TCB  must  ensure  the  clearing  of 
any  secondary  SMT  entries  for  a  segment. 

2.2  PURPOSE  OF  THE  OBJECT  REUSE  REQUIREMENT 

As  stated  in  section  1 .3,  the  object  reuse  requirement  is  primarily  designed  to 
satisfy  DoD  Directive  5200.28  which  requires  that  “Classified  information  and  sensi¬ 
tive  unclassified  information  shall  be  safeguarded  at  all  times  while  in  AIS’s.  Safe¬ 
guards  shall  be  applied  so  that  such  information  is  accessed  only  by  authorized 
persons  .  [4,  page  3]  Without  this  requirement,  storage  objects  could  become 

an  information  transfer  channel  between  disjoint  users  as  the  system  reassigns  the 
objects  upon  user  request.  Assurance  must  be  provided  that  no  data  in  any  storage 
object  is  accessible  upon  allocation  of  that  object— even  if  the  object  is  reallocated 
to  the  subject  having  had  the  most  recent  access  right  to  it. 

2.3  APPLICABILITY  OF  THE  OBJECT  REUSE  REQUIREMENT 

The  TCSEC  object  reuse  requirement  applies  to  all  storage  objects  defined  by 
an  AIS  that  are  protected  by  its  TCB.  The  set  of  storage  objects  often  referred  to  by 
a  user  may  be  (and  likely  are)  different  from  the  set  of  physical  objects  that  the  sys¬ 
tem  must  apply  the  object  reuse  requirement  to.  Whereas  the  user  tends  to  focus 
on  files  or  memory  space,  for  example,  the  system  implements  these  abstract  or 
user-visible  objects  through  the  use  of  real  objects  such  as  disk  blocks,  memory 
pages  or  segments,  records,  bytes,  and  bits.  When  a  user  deletes  a  file,  the  system 
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must  translate  the  deallocation  of  the  virtualized  file  into  the  deallocation  of  the  cor¬ 
responding  control  and  data  blocks  that  actually  implement  the  file.  A  consequence 
of  clearing  the  physical  structures  of  residual  data  must  be  the  clearing  of  the  ab¬ 
stract  object.  Some  common  physical  objects  include  those  items  listed  in  Table  1. 

Common  Physical  Objects 

CPU  Registers 

Floating  Point  Co-processor 
Registers 

Cache  Memory 
Physical  Memory 
Disk  Blocks/Sectors 
Magnetic  Tape  Blocks/Sectors 
Floppy  Disks 

Table  1 

Storage  objects  are  virtualized  into  objects  that  are  visible  to  system  users. 
Some  common  user  objects  are  discussed  in  the  following  section,  along  with  a  de¬ 
scription  of  the  storage  objects  used  to  implement  the  object. 

User  Object  Object  Impiementation 

Virtual  Memory  Virtual  memory  is  implemented  using  structures  similar  to  the 

SMT  shown  in  Figure  1,  and  physical  memory  segments  and 
pages.  The  TCB  maintains  the  structures  defining  the  alloca¬ 
tion  of  physical  memory  to  users.  Virtual  segments  and  pages 
correspond  to  the  physical  segments  and  pages  when  the  vir¬ 
tual  memory  is  mapped  into  physical  memory.  Otherwise,  the 
virtual  memory  resides  in  a  temporary  storage  area  of  a 
physical  disk  drive  or  other  secondary  media. 

Files  Files  are  typically  an  abstraction  of  virtual  memory  and  disk 

blocks  or  sectors.  When  a  file  is  not  being  accessed,  it  is 
commonly  stored  on  a  physical  disk  drive.  The  file  is  defined 
by  a  control  block  which  stores  the  security  critical  informa- 
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tion  of  the  file  and  identifies  the  data  blocks  corresponding  to 
the  file.  The  control  and  data  blocks  are  physically  resident 
on  the  disk  drive  and  are  maintained  by  the  TCB.  When  the 
file  is  being  accessed,  all  or  part  of  the  file  is  mapped  into  the 
virtual  address  space  (virtual  memory)  of  the  process  (sub¬ 
ject)  accessing  the  file. 

Directories  Directories  are  a  special  type  of  file  that  contains  information 

regarding  files.  Directories  reflect  the  names  of  files,  and  up¬ 
on  referring  to  a  specific  filename,  the  directory  provides  in¬ 
formation  to  the  TCB  regarding  the  physical  disk  location  of 
the  file  control  block. 

Virtual  Tape  Drives  Tapes  drives  are  generally  available  to  users  in  one  of  two 

fashions:  allocating  the  entire  tape  drive  to  a  user,  or  provid¬ 
ing  access  to  the  tape  drive  through  files  (as  if  the  tape  drive 
were  a  disk  drive).  When  a  tape  drive  is  completely  allocated 
to  a  user,  the  user  can  utilize  the  tape  drive  in  whatever  man¬ 
ner  desired,  so  long  as  the  system  security  policy  is  adhered 
to.  When  a  tape  drive  is  accessed  through  files,  the  TCB 
maintains  the  information  relevant  to  properly  protect  the  files 
from  unauthorized  access.  This  requires  the  TCB  to  maintain 
control  and  data  block  information,  just  as  is  maintained  for 
files  on  disk  drives. 

The  object  reuse  requirement  applies  to  the  storage  objects  defined  on  an  AIS 
system.  But,  as  is  seen  in  the  previous  discussion  regarding  the  implementation  of 
virtual  objects,  it  is  essential  to  consider  completely  what  storage  objects  are  used 
to  define  the  system’s  objects.  By  carefully  considering  this  visible  object  -  storage 
object  correspondence,  the  system  designer  ensures  the  fulfillment  of  the  object  re¬ 
use  requirement  in  the  AIS  system. 

Reference  [5]  proposes  a  reasonable  methodology  in  conducting  an  object  re¬ 
use  study.  This  process  is  paraphrased  here  as  a  representative  guide  of  how  one 
might  approach  the  problem  during  system  development. 
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Step  1:  Identify  system  objects  by  focusing  on  the  system  documentation  that 
completely  describes  the  TCB  interface.  This  will  contain  the  vast  majority 
of  the  needed  information.  If  a  model  exists  for  the  system’s  security  poli¬ 
cy,  the  objects  should  be  contained  within  it.  If  not,  the  remaining  system 
documentation  and  its  architecture  should  be  useful  in  developing  a  list  of 
object  types. 

Step  2:  Determine  what  system  level  objects  are  used  to  create  the  user-visible 
objects  identified  in  step  1  above.  This  is  the  critical  step  in  the  method¬ 
ology  and  may  represent  the  greatest  amount  of  analysis.  Done  correctly, 
this  step  determines  the  bounds  of  the  study.  The  analysis  requires  an  in- 
depth  understanding  of  the  specific  operating  system  involved  and  knowl¬ 
edge  of  exactly  how  user  objects  are  represented. 

Step  3:  For  each  identified  component,  determine  how  the  system  initially  creates, 
recognizes,  allocates,  and  deallocates  it  and  returns  it  for  system  use.  In¬ 
herent  in  this  procedure  is  the  need  to  verify  that  the  requirements  origi¬ 
nally  stated  for  object  reuse  processing  are  met  for  initialization/allocation 
or  allocation/deallocation,  and  that  the  two  are  equal.  The  remaining  steps 
provide  this  assurance. 

Step  4:  Examine  each  system  object’s  initialization  routine  to  ensure  that  the  re¬ 
quirements  of  object  reuse  are  being  met  when  an  object  is  added  to  the 
system.  That  is,  ensure  it  contains  no  residual  information. 

Step  5:  Examine  the  allocation/deallocation  routines  to  ensure  that  the  requirement 
to  remove  residual  information  has  been  met. 

Step  6:  Identify  all  the  system  operations  used  to  allocate/deallocate  objects  and 
ensure  that  each  invokes  the  object  reuse  mechanisms  necessary  to  pro¬ 
vide  the  required  protection  listed  in  steps  three  through  five  above. 
(Note-do  not  forget  operations  that  “only”  extend,  shorten,  or  move  ob¬ 
jects,  as  these  are  also  allocation/deallocation  operations  worthy  of  scru¬ 
tiny.) 

Step  7:  Ensure  that  the  free  pool  of  objects  itself  is  protected  so  that  unpurged  ob¬ 
jects  cannot  be  accessed  and  read  prior  to  their  reallocation.  If  the  system 
chooses  to  implement  object  reuse  upon  reallocation,  there  may  be  a 
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lengthy  period  of  vulnerability  where  the  object  with  residual  information  is 
stored  in  the  free  pool.  The  free  pool  must  guarantee  protection  of  the  in¬ 
formation  so  it  remains  secure  until  purged  prior  to  reallocation. 

Object  reuse  is  essential  for  all  storage  objects  available  in  an  AIS,  but  an  ex¬ 
amination  of  those  objects  listed  in  Table  1  reveals  that  not  all  such  objects  are  al¬ 
ways  under  TCB  control.  For  example,  the  TCB  can  completely  control  the  ability  to 
access  data  stored  in  physical  memory  but  cannot  protect  data  stored  on  magnetic 
tapes  and  floppy  disks  which  have  been  removed  from  the  system.  These  remov¬ 
able  media  are  subject  to  mistakes  made  by  operators,  and  the  media  may  be  re¬ 
moved  by  system  users  and  accessed  using  off-site  equipment.  In  either  of  these 
cases,  the  TCB  does  not  protect  the  data  stored  on  the  media  and  must  rely  to 
some  extent  upon  physical,  procedural,  or  other  controls  to  ensure  that  data  is  not 
inappropriately  accessed  or  altered.  These  controls  must  be  discussed  in  the  Trust¬ 
ed  Facility  Manual  for  the  system.  These  classes  of  objects  are  depicted  in  Figure  2, 
where  the  cache  and  main  memory  is  normally  always  under  TCB  control,  the  non¬ 
removable  (fixed)  media  is  usually  under  TCB  control,  and  removable  media  is  often 
not  under  TCB  control. 

2.4  SUMMARY 

Object  reuse  mechanisms  ensure  system  resources  are  allocated  and  reas¬ 
signed  among  authorized  AIS  users  in  a  way  which  prevents  the  leak  of  sensitive  in¬ 
formation.  Object  reuse  does  not  necessarily  protect  against  physical  attacks  on  the 
storage  medium.  Without  specifying  how  to  do  it,  the  TCSEC  object  reuse  require¬ 
ment  applies  to  classes  C2  through  A1 ,  with  increasing  assurance  of  proper  execu¬ 
tion  as  the  class  increases.  The  requirement  concerns  storage  objects  accessible 
by  untrusted  users  of  an  AIS;  it  covers  all  TCB-protected  storage  objects  of  an  AIS. 
However,  the  system  designer  may  clear  internal  security  relevant  data  structures  al¬ 
so.  The  system  must  translate  the  deallocation  of  virtualized  files  into  the  dealloca¬ 
tion  of  the  corresponding  control  and  data  blocks  actually  implementing  the  files.  A 
result  of  clearing  the  physical  structures  is  the  clearing  of  the  abstract  object.  All 
storage  objects  require  object  reuse,  but  ail  objects  are  not  always  under  TCB 
control.  Storage  objects  may  or  may  not  correspond  to  the  objects  visible  to  users. 
Additionally,  some  storage  objects  may  need  administrative,  procedural  support  to 
ensure  the  performance  of  object  reuse. 
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STORAGE  OBJECT  CONTROL 


Fully  Under  TCB  Control 

Usually  Under  TCB  Control 

Often  Not  Under  TCB  Control 

Figure  2 
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3.0  IMPLEMENTATION  CONSIDERATIONS  FOR 
OBJECT  REUSE 

3.1  CONSIDERATIONS  FOR  PRIMARY  STORAGE  OBJECTS 

Automated  Information  Systems  (AISs)  rely  upon  a  collection  of  primary  memory 
to  support  the  execution  of  programs.  Object  reuse  on  primary  storage  objects  is 
under  the  control  of  the  AIS’s  TCB.  The  TCB  is  directly  responsible  for  allocating  the 
primary  storage  objects,  placing  data  into  the  objects,  and  determining  when  to  per¬ 
form  object  reuse.  The  physical  memory  provides  virtual  memory  for  user  program 
execution.  When  the  physical  memory  is  allocated  to  a  user,  the  TCB  must  ensure 
that  the  memory  page  contains  no  residual  data.  This  can  be  done  by  purging  the 
memory  page  with  an  overwriting  technique.  For  efficiency  purposes  the  designer 
may  wish  to  use  a  procedure  that  overwrites  and  destroys  residual  data  with  the 
new  data  being  swapped  in  on  behalf  of  a  new  subject  (in  lieu  of  overwriting  with  a 
fixed  or  random  pattern  of  bits).  An  important  part  of  this  technique  is  for  the  system 
designer  to  demonstrate  that,  in  all  circumstances,  the  residual  data  is  overwritten 
prior  to  the  allocation  of  memory  to  the  incoming  subject.  Since  page  frames  in  main 
memory  are  of  fixed  size  and  data  being  swapped  in  or  out  is  not  likely  to  be  an  ex¬ 
act  fit,  it  is  incumbent  upon  the  designer  to  ensure  all  physical  page  frame  space  is 
overwritten  (e.g.,  using  a  fixed  or  random  pattern  of  zeros  and/or  ones  to  purge  the 
memory  from  the  end  of  the  data  being  swapped  in  to  the  end  of  the  physical  page 
frame). 

One  must  not  forget  to  handle  registers.  A  common  error  made  by  system  de¬ 
signers  is  to  forget  to  clear  registers  that  are  new  to  the  product  or  infrequently  used 
by  system  programmers  (e.g.,  floating  point  co-processor  registers). 

Cache  memory  may  present  a  slightly  different  set  of  considerations.  If  a  file  is 
deleted  by  its  owner  and  portions  of  the  file  are  retained  in  cache  memory,  a  later 
request  for  information  contained  in  the  cache  may  be  honored  even  though  the  file 
no  longer  exists  (unless  proper  design  safeguards  are  established).  This  is  espe¬ 
cially  true  if  the  second  request  occurs  very  soon  after  file  deletion. 

When  primary  memory  is  removed  from  the  system  (e.g.,  for  maintenance  or  re¬ 
pair),  it  is  subject  to  the  same  considerations  discussed  later  for  removable  media. 
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3.2  FIXED  MEDIA  METHODS 

In  addition  to  primary  storage  objects,  many  AISs  rely  on  fixed  media  to  contain 
data  for  temporary  (e.g.,  buffer  or  inactive  page  frame)  or  long  term  storage  (e.g., 
file  retention).  This  media  may  be  a  fixed  disk,  the  memory  in  a  terminal,  and  so  on. 
The  system  designer  must  identify  all  physical  objects  {i.e.,  blocks,  bytes,  words) 
that  reside  on  this  media  which  are  used  to  represent  the  more  abstract  objects  the 
user  considers  (i.e.,  files,  records,  programs). 

Data  is  typically  stored  and  retrieved  from  these  kinds  of  media  through  the  use 
of  several  control  mechanisms— each  of  which  might  be  a  storage  object  in  its  own 
right.  For  example,  if  a  fixed  disk  or  drum  is  used  to  provide  a  backing  store  capabil¬ 
ity  for  a  paging  system,  there  are  likely  several  objects  associated  with  the  fixed  me¬ 
dia  that  will  have  object  reuse  requirements.  The  physical  data  blocks  themselves 
must  be  paged  between  usages,  but  in  addition  to  this  obvious  requirement,  one 
must  also  consider  purging  the  associated  entry  for  the  page  in  the  system’s  page 
management  table  and  also  purging  directory  information  that  resides  on  the  media 
itself. 

In  all  cases,  the  TCB’s  ability  to  fully  assure  object  reuse  processing  must  be 
demonstrated.  This  is  normally  accomplished  as  discussed  earlier  in  this  guideline, 
through  the  identification  of  all  objects  (and  their  components)  and  an  examination  of 
each  of  the  routines  that  control  initialization,  allocation,  and  deallocation.  As  with 
primary  memory,  fixed  media  which  is  removed  from  the  system  is  subject  to  the 
same  considerations  discussed  later  for  removable  media. 

To  ensure  the  system  is  started  in  an  initially-secure  state,  the  fixed  reusable 
medium  must  be  initialized  to  an  appropriate  condition.  Clearly,  the  extent  of  the 
initialization  depends  on  the  type  of  fixed  storage  objects  involved:  main  memory 
storage  units  must  be  initialized  each  time  a  trusted  system  is  started  up,  while 
longer-term  storage  (e.g.,  disks)  would  have  to  be  initialized  only  on  first  startup  or 
perhaps  as  part  of  a  recovery  process  after  a  system  failure. 

One  can  design  systems  and  their  attached  devices  (printers,  terminals,  etc.) 
that  have  residual  memory  to  be  cleared  with  a  command  issued  by  the  main 
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processor’s  TCB.  However,  for  open  architectures*,  there  is  little  that  can  be  done 
from  a  TCB  to  (re)initialize  the  equipment  for  reallocation.  One  technique  that  works 
with  some  equipment  is  to  power  it  off,  then  on.  However,  such  practice  is  hard  on 
the  equipment  and  is  sometimes  not  possible  without  modifying  the  equipment,  or 
providing  TCB-controlled  power  (outlets)  for  the  equipment.  The  more  likely  ap¬ 
proach  for  connected  terminal  equipment  having  its  own  processing  capability  is  to 
ensure  the  terminal  device  itself  enforces  the  object  reuse  requirement. 

3.3  REMOVABLE  MEDIA  METHODS 

This  section  discusses  some  possible  implementation  approaches  that  could  be 
the  basis  for  an  object  reuse  mechanism  for  removable  (or  removed)  media.  Re¬ 
movable  media  represents  a  special  case  because  it  can  physically  be  removed 
from  the  system.  This  means  that  it  no  longer  comes  under  TCB  controls  and  thus 
the  automated  object  reuse  procedures  must  be  augmented  by  physical  and  proce¬ 
dural  controls  described  in  the  Trusted  Facility  Manual. 

First,  any  of  the  methods  used  for  fixed  medium  systems  can  be  used.  As  in 
the  fixed  storage  class,  it  is  important  to  overwrite  in  complete  physical  allocation 
units  (e.g.,  sectors,  clusters,  blocks,  tracks,  cylinders).  The  actual  allocation  units 
are  operating  system  dependent. 

As  an  example,  one  logical  method  may  apply  to  tape  storage.  If  the  system 
being  rated  has  no  I/O  commands  accessible  to  users  that  can  force  the  reading  of 
a  tape  beyond  an  end-of-file  (EOF)  mark,  the  TCB  can  write  an  EOF  mark  at  the  be¬ 
ginning  of  all  ‘scratch’  tapes.  Of  course,  the  question  is  what  informs  the  TCB  that  a 
scratch  tape  is  being  introduced  to  the  system.  As  will  be  seen  below,  this  is  a  spe¬ 
cific  instance  of  a  more  general  question  of  how  to  reintroduce  removable  media  to 
the  control  of  the  TCB. 

In  general,  overwriting  storage  is  feasible  if  the  amount  of  storage  to  be  over¬ 
written  is  relatively  small,  and  the  overwriting  is  relatively  fast.  Thus,  for  most  ‘main 
memory’  usage,  overwriting  is  feasible.  It  is  also  feasible  for  diskettes  and  other 


’Open  Architectures  -  systems  designed  with  well  known  and  industry  standard  interfaces  such  that 
arbitrary  peripheral  (I/O)  devices  can  be  attached  and  easily  controlled. 
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small  removable  disk  media,  such  as  disk  cartridges,  especially  if  a  multipro- 
grammed  daemon  owned  by  the  TCB  performs  the  overwriting. 

If  real-time  overwriting  is  not  feasible  (a  case  for  most  large  removable  storage 
media),  then  some  off-line  method  is  indicated.  Only  two  physical  methods  appear 
suitable:  degaussing  (demagnetizing)  and  independent  off-line  overwriting.  This 
guideline  cannot  recommend  any  specific  degausser,  although  Government- 
approved  degaussers  are  available.  One  commercially  available  model  can  com¬ 
pletely  degauss  up  to  10  tapes,  or  a  removable  disk,  in  one  operation  (which  takes 
less  than  30  seconds).  Degaussers  that  have  been  approved  to  degauss  classified 
tapes  or  disks  are  listed  on  the  NSA  Degausser  Products  List  [3].  The  actual  proce¬ 
dures  used  for  degaussing  are  beyond  the  scope  of  this  guideline  because  they 
again  are  not  processes  a  TCB  can  control. 

On-line  overwriting  is  a  method  the  TCB  could  control,  possibly  by  not  releasing 
a  tape  for  removal  or  reallocation  until  its  entire  length  is  overwritten.  However,  the 
performance  impact  of  using  on-line  overwrite  alone  is  so  onerous  that  it  is  not  a 
practical  solution.  Perhaps  an  efficient  method  of  handling  off-line  overwrite  is  to 
dedicate  a  small  computer  system  to  that  function,  with  one  or  more  tape  or  disk 
drives  to  hold  the  medium  being  prepared  for  reuse.  If  off-line  overwriting  is  done, 
there  is  a  lingering  concern  over  whether  the  overwrite  is  complete.  Even  if  off-line 
overwriting  is  an  extension  of  the  object  reuse  mechanism,  one  may  have  to  verify 
the  overwrite  mechanism  always  overwrote  the  entire  medium. 

3.4  MANAGEMENT  OF  REMOVABLE  MEDIA 

The  problem  with  off-line  object  reuse  preparation  is  not  with  the  method  used 
to  eliminate  the  residue  from  previous  use,  but  the  management  of  the  reintroduc¬ 
tion  to  the  TCB  of  media  that  was  degaussed  or  overwritten.  From  the  TCB’s  per¬ 
spective,  it  must  know  it  is  allocating  an  object  (storage  medium)  that  has  been 
properly  processed  for  reuse.  In  the  case  of  the  fixed  media,  the  TCB  itself  largely 
has  total  control  of  the  process,  and  the  design  verification  process  assures  that  the 
TCB  only  allocates  from  properly  processed  reusable  objects. 

With  removable  media,  the  TCB  must  be  informed  in  some  manner  that  a  new 
or  reprocessed  (degaussed  or  off-line  overwritten)  storage  object  is  being  intro¬ 
duced  into  the  allocable  storage  object  pool.  Further,  since  there  may  be  an 
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arbitrary  time  lapse  between  a  medium  being  accepted  for  reuse  and  its  actual  re¬ 
use,  the  TCB  needs  some  way  to  identify  removable  storage  objects  that  have  been 
accepted  for  reuse.  This  is  certainly  a  candidate  for  incorporation  into  the  system’s 
Trusted  Facility  Manual. 

Clearly,  something  like  the  “.  .  .  mechanism  by  which  the  TCB  and  an  autho¬ 
rized  user  reiiabiy  communicate  ...”  to  designate  the  single  level  of  information  be¬ 
ing  imported  or  exported  via  single-level  communications  or  I/O  devices  could  be 
adapted  to  allow  an  operator  to  reliably  inform  the  TCB  that  a  new  or  reprocessed 
removable  medium  is  being  reintroduced  into  the  pool  of  allocable  storage  objects. 
At  the  lower  classes  the  mechanism  might  be  the  operator’s  console.  At  higher  level 
classes,  it  might  be  a  variant  on  the  Trusted  Path  mechanisms  between  users  and 
the  TCB. 

How  the  TCB  identifies  the  removable  storage  object  as  being  accepted  for  re¬ 
use  is  again  a  detail  that  is  very  system-dependent.  It  could  range  from  TCB- 
readable  physical  identification  numbers  recorded  on  the  medium  being  entered  into 
a  TCB-managed  and  -controlled  inventory  file,  to  the  TCB  magnetically  (or  optically) 
recording  on  the  medium  an  encrypted  serial  number  which  it  also  keeps  in  the  in¬ 
ventory  of  available  allocable  storage  objects. 

If  degaussing  is  used  as  the  off-line  process  to  prepare  a  removable  storage 
object  for  reuse,  it  is  likely  the  operating  system  must  prepare  it  for  use  by  writing 
timing  tracks  or  sector  addresses  and  by  performing  other  low-level  formatting  of  the 
medium  without  which  the  medium  can  not  be  used  by  the  system.  This  may  be  suf¬ 
ficient  assurance  that  the  TCB  has  a  chance  to  identify  the  storage  object.  However, 
the  TCB  must  still  maintain  the  inventory  of  allocable  storage  objects  and  assure 
that  only  previously  accepted  storage  objects  are  allocated.  As  a  consequence,  it  is 
recommended  that  formatting  of  degaussed  media  is  done  as  a  separate  function 
not  associated  with  reentering  the  medium  into  the  pool  of  allocable  storage  objects, 
and  the  acceptance  and  identification  process  be  completely  separate  from  any  me¬ 
dia  preparation  required  by  the  system. 

While  there  is  no  requirement  to  apply  such  a  technique  to  all  removable  media, 
the  notion  of  economy  of  mechanism  suggests  it  would  be  easier  to  understand  if  all 
removable  reusable  storage  is  handled  in  the  same  way. 
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OBJECT  REUSE  GUIDELINE 


3.5  SUMMARY 

An  AIS’s  TCB  controls  object  reuse  on  storage  media  (primary  storage,  fixed 
media,  and  removable  media).  Demonstrate  the  TCB’s  ability  to  assure  proper  ob¬ 
ject  reuse  by  identifying  all  physical  objects  on  this  media  which  represent  abstract 
user  objects  and  by  examining  the  routines  controlling  initialization,  allocation,  and 
deallocation.  To  ensure  an  initially-secure  state  for  the  system,  initialize  the  media  to 
an  appropriate  condition.  Physical  and  procedural  controls  augment  the  automated 
object  reuse  procedures  of  storage  media  (even  primary  memory  and  fixed  media) 
removed  from  the  system  and,  thus,  from  TCB  controls. 

If  real-time  overwriting  of  removable  storage  is  not  practical,  overwrite  it  off-line 
or  degauss  it.  Dedicating  a  small  computer  system  to  overwrite  storage  off-line  is  an 
efficient  method.  When  degaussing  is  used,  do  not  connect  media  formatting  with 
reentering  the  media  into  the  pool  of  allocable  storage  objects.  Separate  the  accep¬ 
tance  and  identification  process  from  media  preparation.  Handle  all  removable  stor¬ 
age  the  same  way.  Incorporate  this  into  the  system’s  Trusted  Facility  Manual. 

Managing  the  reintroduction  of  media  to  the  TCB  is  a  problem  with  off-line  ob¬ 
ject  reuse  preparation.  The  TCB  must  know  it  is  allocating  a  properly  processed  ob¬ 
ject.  For  fixed  media,  the  TCB  largely  controls  the  process,  and  design  verification 
assures  that  the  TCB  allocates  properly  processed  objects.  With  removable  media, 
the  TCB  is  told  when  new  or  reprocessed  storage  objects  are  put  into  the  storage 
object  pool.  How  this  is  done  is  very  system-dependent. 
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GLOSSARY 


ASSURANCE 

A  measure  of  confidence  that  the  security  features  and  architecture  of  an 
automated  information  system  accurately  mediate  and  enforce  the  security 
policy. 

AUTHORIZATION 

The  granting  of  access  rights  to  a  user,  program,  or  process. 

BROWSING 

The  act  of  searching  through  storage  to  locate  or  acquire  information  without 
necessarily  knowing  of  the  existence  or  the  format  of  the  information  being 
sought. 

OBJECT 

A  passive  entity  that  contains  or  receives  information.  Access  to  an  object 
potentially  implies  access  to  the  information  it  contains.  Examples  of  objects 
are:  records,  blocks,  pages,  segments,  files,  directories,  directory  trees, 
programs,  bits,  bytes,  words,  fields,  processors,  video  displays,  keyboards, 
clocks,  printers,  and  network  nodes. 

SCAVENGING 

Searching  through  residue  (i.e.,  objects  and/or  their  components)  to  acquire 
unauthorized  data. 

STORAGE  ELEMENT 

The  hardware  (e.g.,  main  memory,  disk  sectors,  magnetic  tape)  used  to  store 
data  that  is  accessible  to  a  user’s  programs. 

STORAGE  OBJECT 

An  object  that  supports  both  read  and  write  accesses. 

SUBJECT 

An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device,  that 
causes  information  to  flow  among  objects  or  changes  the  system  state. 
Technically,  a  process/domain  pair. 
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GLOSSARY 


TRUSTED  COMPUTING  BASE  (TCB) 

The  totality  of  protection  mechanisms  within  a  computer  system— including 
hardware,  firmware,  and  software— the  combination  of  which  is  responsible  for 
enforcing  a  security  policy.  A  TCB  consists  of  one  or  more  components  that 
together  enforce  a  unified  security  policy  over  a  product  or  system.  The  ability 
of  a  TCB  to  correctly  enforce  a  security  policy  depends  solely  on  the 
mechanisms  within  the  TCB  and  on  the  correct  input  by  system  administrative 
personnel  of  parameters  {e.g.,  a  user’s  clearance  level)  related  to  the  security 
policy. 
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